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Abstract 


Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) 
established using the Resource Reservation Protocol Traffic 
Engineering (RSVP-TE) extensions may be signaled with a set of LSP- 
specific attributes. These attributes may be carried in both Path 
and Resv messages. This document specifies how LSP attributes are to 
be carried in RSVP Path and Resv messages using the Routing Backus- 
Naur Form and clarifies related Resv message formats. This document 
updates RFC 4875 and RFC 5420. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6510. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Signaling in support of Multiprotocol Label Switching (MPLS) and 
Generalized MPLS (GMPLS) point-to-point Label Switched Paths (LSPs) 
is defined in [RFC3209] and [RFC3473]. [RFC4875] defines signaling 
support for point-to-multipoint (P2MP) Traffic Engineering (TE) LSPs. 


Two LSP Attributes objects are defined in [RFC5420]. These objects 
may be used to provide additional information related to how an LSP 
should be set up when carried in a Path message and, when carried in 
a Resv message, how an LSP has been established. The definition of 
the objects includes a narrative description of related message 
formats (see Section 9 of [RFC5420]). This definition does not 
provide the related Routing Backus-Naur Form (BNF) [RFC5511] that is 
typically used to define how messages are to be constructed using 
RSVP objects. The current message format description has led to the 
open question of how the LSP Attributes objects are to be processed 
in Resv messages of P2MP LSPs (which are defined in [RFC4875]). 


This document provides the BNF for Path and Resv messages carrying 
the LSP Attributes object. The definition clarifies how the objects 
are to be carried for all LSP types. Both Path and Resv message BNF 
is provided for completeness. 
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This document presents the related RSVP message formats as modified 
by [RFC5420]. This document modifies formats defined in [RFC3209], 
[RFC3473], and [RFC4875]. See [RFC5511] for the syntax used by RSVP. 
Unmodified formats are not listed. An example of a case where the 
modified formats are applicable is described in [RFC6511]. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Path Messages 


This section updates [RFC4875]. Path message formatting is 
unmodified from the narrative description provided in Section 9 of 
[RFC5420]: 


The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object 
MAY be carried in a Path message.... 


The order of objects in RSVP-TE messages is recommended, but 
implementations must be capable of receiving the objects in any 
meaningful order. 


On a Path message, the LSP_ATTRIBUTES object and 
LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed 
immediately after the SESSION_ATTRIBUTE object if it is present, 
or otherwise immediately after the LABEL REQUEST object. 


If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES 
object are present, the LSP_REQUIRED_ATTRIBUTES object is 
RECOMMENDED to be placed first. 


LSRs MUST be prepared to receive these objects in any order in any 
position within a Path message. Subsequent instances of these 
objects within a Path message SHOULD be ignored and MUST be 
forwarded unchanged. 


2.1. Path Message Format 


This section presents the Path message format as modified by 


[RFC5420]. Unmodified formats are not listed. 
<Path Message> ::= <Common Header> [ <INTEGRITY> ] 
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...] 


[ <MESSAGE_ID> ] 
<SESSION> <RSVP_HOP> 
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<TIME_VALUES> 

[ <EXPLICIT_ROUTE> ] 
<LABEL_REQUEST> 

[ <PROTECTION> ] 

<LABEL_SET> ... ] 
<SESSION_ATTRIBUTE> ] 
<LSP_REQUIRED_ATTRIBUTES> ... ] 
<LSP_ATTRIBUTES> ... ] 
<NOTIFY_REQUEST> ] 
<ADMIN_STATUS> ] 

[ <POLICY_DATA> ... ] 

<sender descriptor> 

[<S2L sub-LSP descriptor list>] 


(en en Bl oes oe ee Bl 


Note that PathErr and PathTear messages are not impacted by the 
introduction of the LSP Attributes objects. 


3. Resv Messages 


This section updates [RFC4875] and [RFC5420]. Section 9 of [RFC5420] 
contains the following text regarding Resv messages: 


The LSP_ATTRIBUTES object MAY be carried in a Resv message. 


The order of objects in RSVP-TE messages is recommended, but 
implementations must be capable of receiving the objects in any 
meaningful order. 


On a Resv message, the LSP_ATTRIBUTES object is placed in the flow 
descriptor and is associated with the FILTER_SPEC object that 
precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be 
placed immediately after the LABEL object. 


LSRs MUST be prepared to receive this object in any order in any 
position within a Resv message, subject to the previous note. 
Only one instance of the LSP_ATTRIBUTES object is meaningful 
within the context of a FILTER_SPEC object. Subsequent instances 
of the object SHOULD be ignored and MUST be forwarded unchanged. 


This means that LSP attributes may be present per sender (LSP) and 
allows for the LSP Attributes object to be modified using make- 
before-break (see [RFC3209]). This definition is sufficient for 
point-to-point ([RFC3209] and [RFC3473]) LSPs and the special case 
where all point-to-multipoint source-to-leaf (S2L) sub-LSPs 
([RFC4875]) report the same operational status (as used in 
[RFC5420]). However, this definition does not allow for different 
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egress Label Switching Routers (LSRs) to report different operational 
statuses. In order to allow such reporting, this document adds the 


fol 


Thi 


lowing definition: 


An LSR that wishes to report the operational status of a (point- 
to-multipoint) S2L sub-LSP may include the LSP Attributes object 
in a Resv message or update the object that is already carried in 
a Resv message. LSP Attributes objects representing S2L sub-LSP 
status MUST follow a S2L_SUB_LSP object. Only the first instance 
of the LSP Attributes object is meaningful within the context of a 
S2L_SUB_LSP object. Subsequent instances of the object SHOULD be 
ignored and MUST be forwarded unchanged. 


When an LSP Attributes object is present before the first 
S2L_SUB_LSP object, the LSP Attributes object represents the 
operational status of all S2L sub-LSPs identified in the message. 
Subsequent instances of the object (e.g., in the filter spec or 
the S2L sub-LSP flow descriptor) SHOULD be ignored and MUST be 
forwarded unchanged. When a branch node is combining Resv state 
from multiple receivers into a single Resv message and an LSP 
Attributes object is present before the first S2L_SUB_LSP object 
in a received Resv message, the received LSP Attributes object 
SHOULD be moved to follow the first received S2L_SUB_LSP object 
and then SHOULD be duplicated for, and placed after, each 
subsequent S2L_SUB_LSP object. 


Resv Message Format -- Per LSP Operational Status 


s section presents the Resv message format for LSPs as modified by 


[RFC5420] and can be used to report operational status per LSP. 
Unmodified formats are not listed. The following is based on 
[RFC4875]. 

<FF flow descriptor list> = <FF flow descriptor> 


<FF 


<SE 


<SE 


Berger 


[ <FF flow descriptor list> ] 
flow descriptor> 2:5 <FLOWSPEC> ] <FILTER _SPEC> <LABEL> 
<LSP_ATTRIBUTES> ... ] 
<RECORD_ROUTE> ] 
<S2L sub-LSP flow descriptor list> ] 


(ee ee ee A 


flow descriptor> ::= <FLOWSPEC> <SE filter spec list> 
filter spec list> ::= <SE filter spec> 

[ <SE filter spec list> ] 
& Swallow Standards Track [Page 5] 
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<SE filter spec> ::= <FILTER_SPEC> <LABEL> 
[ <LSP_ATTRIBUTES> ... ] 
[ <RECORD_ROUTE> ] 
[ <S2L sub-LSP flow descriptor list> ] 


3.2. Resv Message Format -- Per S2L Operational Status 


This section presents the Resv message format for LSPs as modified by 
this document and [RFC5420], and can be used to report operational 
status per S2L sub-LSP. Unmodified formats are not listed. The 
following is based on [RFC4875]. 


<FF flow descriptor> 


[ <FLOWSPEC> ] <FILTER_SPEC> <LABEL> 
[ <RECORD_ROUTE> ] 
[ <S2L sub-LSP flow descriptor list> ] 


<SE filter spec> 


<FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] 
[ <S2L sub-LSP flow descriptor list> ] 


<S2L sub-LSP flow descriptor list> ::= 
<S2L sub-LSP flow descriptor> 
[ <S2L sub-LSP flow descriptor list> ] 


<S2L sub-LSP flow descriptor> ::= <S2L_SUB_LSP> 
[ <LSP_ATTRIBUTES> ... ] 
[ <P2MP_SECONDARY_RECORD_ROUTE> ] 


3.2.1. Compatibility 


A node that supports [RFC4875] and [RFC5420], but not this document, 
will interpret the first LSP Attributes object present in a received 
message, which is formatted as described in this document, as 
representing LSP operational status rather than S2L sub-LSP status. 
It is unclear if this is a significant issue as the LSP Attributes 
object is currently considered to be an unsuitable mechanism for 
reporting operational status of P2MP LSPs, for example, see Section 
2.1 of [RFC6511]. The intent of this document is to correct this 
limitation; it is expected that networks that wish to make use of 
such operational reporting will deploy this extension. 


4. Security Considerations 


This document clarifies usage of objects defined in [RFC5420]. No 
new information is conveyed; therefore, no additional security 
considerations are included here. For a general discussion on MPLS- 


and GMPLS-related security issues, see the MPLS/GMPLS security 
framework [RFC5920]. 
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